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ABSTRACT: A system for determining the cause of lost, delayed or erroneous responses in a 
network for authorizing payment card transactions from the point of view of the point-of-sale 
terminal that forms part of the network. A request for authorization is entered into the terminaK 
the termi nal transmits a message requesting authorization to a computer in the network, and 
receives a return message in response from the computer. The terminal logs the origination time 
of the message, the elapsed time between the origination time and the time at which it receives 
the return message, the transaction serial number, and, optionally, other data for each request for 
authorization. In a variation, each computer in the network adds a time stamp to the message as 
the message returns from the computer to the terminal. The time stamp shows the computer 
elapsed time, computer identity, authorization status, etc. The terminal additionally logs the time 
stamps received in the return message. In a further variation, each computer in the network adds 
a time stamp to the message each time the computer processes the message. The computer time 
stamp shows the computer transit tune instead of the computer elapsed time. In all variations, the 
terminal uploads the logged data from time-to-time for analysis, preferably by a computer in the 
network. 
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ABPL: A system for determining the cause of lost, delayed or erroneous responses in a network 
for authorizmg payment card transactions from the point of view of the point-of-sale terminal that 
forms part of the network. A request for authorization is entered into the terminal, the terminal 
transmits a message re questing authorization to a computer in the network, and receives a return 
message in response from the computer. The terminal logs the origination time of the message, 
the elapsed tune between the origination time and the time at which it receives the return message, 
the transaction serial number, and, optionally, other data for each request for authorization. In a 
variation, each computer in the network adds a time stamp to the message as the message returns 
from the computer to the terminal. The time stamp shows the computer elapsed time, computer 
identity, authorization status, etc. The terminal additionally logs the tune stamps received in the 
return message. In a further variation, each computer in the network adds a time stamp to the 
message each tune the computer processes the message. The computer time stamp shows the 
computer transit time instead of the computer elapsed time. In all variations, the terminal uploads 



1 




±e logged data from time-to-time for analysis, preferably by a computer in the network. 

BSPR: Typically, the presentation of the draft and the payment by the issuer is accomplished 
electronically through a Imked computer network. A data control center is used to transfer fiinds 
electronically. The data control center is electronically connected to a plurality of issuers and also 
to a plurality of merchant member banks. Information passing between merchant member banks 
and issuers is routed thr ough the data control center. 

BSPR: If the merchant member bank is, in fact, the issuer of the particular bank card, the message 
requesting authorizati on can be handled internally. More particularly, the merchant member 
bank's computer checks its account file for the cardholder and decides to grant or deny 
authorization of the transaction. In most cases however, the issuer of the card is different from 
the merchant member bank. In tfiis situation, the merchant member bank computer electronically 
routes the request for authorization to the data control center. The data control center then 
forwards the message to the issuer of the payment card. The remote issuer's computer checks its 
account file on the cardholder to determine if the card has been reported lost or stolen, or if the 
customer has exceeded his/her credit limits, or has depleted the fiinds in his/her deposit account. 
The issuer then transmits a return message, either granting or denying authorization of the 
transaction, back to the merchant through the data control center and the merchant's merchant 
member bank. 

BSPR: The network just described is an over sunplification: present commercial networks 
typically include additional computers, such as a computer in the store, a computer in the store's 
data processing center, and various switching and distribution computers between the store and 
the member merchant bank's computer, between the member merchant bank's computer and the 
data control center, and between the data control center and the issuer's computer. The various 
computers are often separated by thousands of miles and are interconnected by dial-up or 
dedicated communication links. 

BSPR: In the following description of the invention, a transaction authorization network comprises 
a point-of-sale terminal connected through a communication link to a chain of computers 
connected bv communication links, the computers including at least a data control center and an 
issuer's computer. The point-of-sale terminal and computers each constitute a node in the 
transation authorization network. The invention provides for monitoring the quality of the 
transaction authorization network from the pomt of view of the point of sale from the origination 
by the point-of-sale termmal of a message requesting authorization of a transaction to the receipt 
by the terminal of a message granting or denying authorization, or cancellation of the request. The 
point-of-sale terminal gathers and stores for later analysis timing and resuh data pertaining to each 
message requesting authorization that the terminal attempts to transmit. 

BSPR: In a first embodiment of the service quality monitoring system according to the invention, 
the point-of-sale terminal measures and logs the terminal elapsed time for each message requesting 
authorization of a transaction that the terminal attempts to transmit, irrespective of whether the 
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terminal receives a response to the message from the transaction authorization network . The 
termmal elapsed time for a message requesting authorization is the time required for the terminal 
to receive a message m response to the message requesting authorization, and is preferably the 
time that elapses between the origination time and the receive time. The origination time is 
preferably the time at which the point-of-sale terminal begins to establish communication with the 
computer to which it is connected so that it can transmit a message requesting authorization. The 
receive time is the time at which the terminal receives the return message back from the computer 
to which it is connected. Alternatively, the terminal can log data from which the terminal elapsed 
time can be calculated. The point-of-sale terminal preferably additionally logs the origination time 
of each message. Optionally, the terminal can also log a message identifier, such as the transaction 
serial number or the payment card number for each message it attempts to send, and the 
authorization status data in the return message. 

BSPR: The terminal from tune-to-time uploads its logged data for analysis. This is preferably 
done in response to a command issued by a computer in the transaction autiiorization network, and 
the data is preferably uploaded to a computer in the network. From the logged data, the total tune 
required by the transaction authorization network to authorize each transaction entered into the 
point-of-sale terminal, and the number of requests for authorization that are not responded to, can 
be determined. By combining the data from a number of point-of-sale terminals, and/or by 
correlating the data logged by the point-of-sale terminal with data logged elsewhere in the 
transaction authorization network, e.g.. the computer of the issuer, the number of requests for 
authorization that receive an erroneous response, and the cause of delays and/or errors, may be 
determined. The first embodiment of the service quality monitoring system does not allow errors 
and the cause of delays and/or errors to be determined directly, however. 

BSPR: A second embodiment of the service quality monitoring system according to the invention 
gathers more detailed information about the service quality provided by the transaction 
authorization network by applying the principles of the first embodiment of the invention to each 
computer, or selected computers, in the transaction authorization network. The additional data 
enables the part of the network causing delayed, lost, or inaccurate messages to be determined 
more directly. For each message requesting authorization, each computer in the network measures 
a computer elapsed time. The computer elapsed time is the time that elapses between the time at 
which the computer receives the message fro m the previous node in the network, and the time at 
which the computer tra nsmits the message back to the previous node in the network . Instead of 
logging the computer elapsed time, the computer adds a computer time stamp to the message, the 
computer time stamp becoming part of the message. The computer time stamp includes the 
computer elapsed time, and preferably also includes identity data identifying the computer, and 
an action code, indicating what the computer did with the message (e.g., a "forwarded 
authorization request" code, or an "issued transaction approved" code, etc.). 

BSPR: The third embodiment of the service quality monitoring system accordmg to the invention 
is a variation on the second embodiment that provides an even more detailed picture of the quality 
of service provided by the transaction authorization network. In the third embodiment of the 
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invention, each computer, or selected computers, in the network adds a computer time stamp to 
the message each time the message passes through the computer. Thus, a computer adds a 
computer time stamp to the message both when the message is travelling from the point-of-sale 
terminal to the issuer's computer and when the message is travelling from the issuer's computer 
back to the point-of-sale terminal. Each computer time stamp includes the computer transit time 
instead of the computer elapsed time used in the second embodiment. The computer transit time 
which is the time that elapses between the time at which the computer receives the message from 
the previous node in the network and the time at which the computer passes the message on to the 
next node in the network. Alternatively, the computer time stamp can include time data that 
enables the computer transit time to be calculated. 

DEPR: FIG. 1 shows a block diagram of a basic transaction authorization network having three 
nodes, the point-of-sale terminal 1, the data control center 11, and the computer of the issuer 21. 
The nodes of the network are connected in a chain by the communication links 6 and 16. The 
point-of-sale terminal 1 is one of a plurality of point-of-sale terminals (not shown) connected 
through dial-up or dedicated communication links to the data control center 1 1 . The point-of-sale 
terminal 1 is connected to the data control center 1 1 through the communication link 6. The data 
control center 11 has several functions in providing cashless transactions: only its role in the 
transaction authorization process will be described here. The data control center 11 is also 
connected through dial-up or dedicated communication links to the computers of a plurality of 
issuers (not shown). The computer of one issuer 21 is shown in FIG. 1. The computer of the 
issuer 21 is connected via the communication link 16 to the data control center 11. 

DEPR: In this simple network, the pomt-of-sale terminal remains on line awaiting the message 
to return from the data control center 11, and can receive the message immediately. In a more 
complex network, the point-of-sale terminal 1 may be receiving other messages, and the data 
control center may have to wait until it receives a go-ahead signal from the point-of-sale terminal 
before it can transmit the message. The data control center transmits the message to the point-of- 
sale terminal, the point-of-sale terminal reads the authorization status information in the return 
message received from the data control center, and may display it to the merchant or, assuming 
the transaction is approved, proceed with printing a voucher for the cardholder to sign, completing 
the transaction. 

DEPR: FIG. 2 shows a more typical transaction authorization network having eight nodes 
connected in a chain by communication links. The point-of-sale terminal is connected by the data 
link 36 to the in-store computer 41. The in-store computer 41 is connected by the data link 46 to 
the store's regional or national data processing center 51. The store's data processing center is 
connected by the data link 56 to the merchant member bank's computer 61 . The merchant member 
bank's computer 61 is connected via the data links 66 and 76, and the regional switching computer 
71, to the data control center 11. The data control center 11 is connected to the computer of the 
issuer 21 via data links 86 and 96 and the national switching computer 81. To obtain authorization 
of a transaction, the point-of-sale terminal 1 sends a message though this network to the computer 
of the issuer 21 and the computer of the issuer 21 sends the return message back through the same 
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network to the point-of-sale terminal 1. In some systems the message may return to the point-of- 
sale terminal through a different network of comparable complexity. 

DEPR: A computer in the transaction authorization network, such as the data control center 1 1 , 
transmits a command to the point-of-sale terminal 1 from time-to-time instructing the terminal to 
upload its log to a computer in the network for analysis. On receiving the upload command, the 
terminal 1 transfers the contents of its log via the communication link 6 and the network to at least 
one other computer in the network. Alternatively, the terminal 1 can be programmed to upload 
its data spontaneously after a preset time interval or after a preset number of transactions. As a 
fiirfher alternative, the termmal 1 can store its logged data on a removable storage medium, such 
as a magnetic tape or disk, and its logged data can be uploaded by removing the removable 
medium from time-to-time and transporting it to a central location for analysis. 

DEPR: The second embodiment of a service quality monitoring system according to the invention 
gathers additional data relating to the quality of service provided by the transaction authorization 
network by applying the principles of the first embodiment of the invention to the computers, or 
selected computers, in the network. The additional data enables the part of the network causing 
delayed, lost, or inaccurate messages to be determined. For each message requesting authorization 
passing through the transaction authorization network, each computer, such as the data control 
center 11 and the computer of the issuer 21, measures a computer elapsed time. The computer 
elapsed time is the time that elapses between the time at which the computer receives the message 
from the previous nod e in the network, and the time at which the computer transmits the message 
back to the previous node in the network . For example, the data control center 11 receives a 
message from the point-of-sale terminal 1 at 10:00:00 hrs, but does not determine the identity of 
the issuer 21 of the payment card until 10:00:07. The data control center then immediately 
attempts to forward the message to the issuer institution 21, but the issuer's computer is busy and 
does not give the go-ahead to transmit the message until 10:00:10. The data control center 11 
receives the message back from the issuer's computer at 10:00:12. The point-of-sale terminal is 
busy and does not give the data control center the go-ahead to transmit the message back to it until 
10:00:18. The computer elapsed time for the data control center is 18 seconds, from 10:00:00 to 
10:00:18. The computer elapsed time for the computer of the issuer 21 is 2 seconds, from 
10:00: 10 to 10:00:12. 

DEPR: As in the first embodiment of the invention, the point-of-sale terminal 1 receives a 
command from a comp uter in the transaction authorization network from time-to-time instructing 
it to upload its logged time stamps for analysis. The terminal 1 can upload its data to the data 
control center 11, or to any other computer in the network. Alternatively, the terminal 1 can be 
programmed to upload its data spontaneously after a preset time interval or after a preset number 
of transactions. As a ftirther alternative, the point-of-sale terminal 1 can store its logged data on 
a removable storage medium, such as a magnetic tape or disk, and its logged data can be uploaded 
by removing the removable medium from time-to-time and transporting it to a central location for 
analysis. 
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DEPR: FIG. 3 shows how the second embodiment of the invention is applied to the simple 
transaction authorization network shown in FIG. 1. The point-of-sale terminal 1 adds a terminal 
time stamp, consisting of the transaction serial number only, to the message, and transmits the 
message including the terminal tune stamp to the data control center 11. When the data control 
center receives the message it logs the message and starts measuring the computer elapsed time 
for the message. The data control center 11 forwards the message to the issuer 21. The message 
still includes one time stamp. The computer of the issuer 21 receives the message, logs it and 
starts measuring the computer elapsed time for the message. The computer of the issuer processes 
the message, and adds its "Computer I" time stamp, which includes the computer elapsed time for 
the computer of the issuer, to the processed message when it transmits the processed message back 
to the data control center . The message now includes two tune stamps. 

DEPR: In table 1, the processing time is the time required for the node to process the message. 
In the data control center 11, this includes determining the identity of the issuer. In the computer 
of the issuer 21, this includes determining whether or not to authorize the transaction. The 
conmiunication time is the time required to establish conmiunication with the next node in the 
network, to wait for the goahead from the next node in the network to transmit the message, and 
to transmit the message . The elapsed time for the computer of the issuer is shown by the bracket 
marked "13." "I" denotes the computer of the issuer, "3" is the computer elapsed time of 3 
seconds. The computer elapsed time is made up of 2 seconds of processing time and 1 second of 
communication time. The elapsed time for the data control center is shown by the bracket marked 
"Dll." "D" denotes the data control center, 11 is the computer elapsed time of 11 seconds. The 
computer elapsed time of the data control center is made up of 1 second processing time and 2 
seconds of communication time when the data control center forwards the message from the point- 
of-sale terminal 1 to the computer of the issuer 21, 3 seconds for the computer elapsed time for 
the computer of the issuer 21, and 1 second of processing time and 4 seconds of communication 
time when the data control center forwards the return message from the computer of the issuer 21 
to the point-of-sale terminal 1. The elapsed time of point-of-sale terminal 1 is shown by the 
bracket marked "T13." "T" indicates the point-of-sale terminal, 13 is the terminal elapsed time 
of 13 seconds. The termmal elapsed time is made up of 11 seconds of computer elapsed time for 
the data control center and 2 seconds of terminal conmiunication time. 

DEPR: The data control center 11 receives the message from the computer of the issuer 21. 
prpcesseg the mesgagp, and waits for some time before it can forward the message to the point-of- 
sale terminal 1. When the data control center forwards the message to the point-of-sale terminal, 
it stops measuring its computer elapsed time for the message and adds its computer time stamp 
to the message. For the message shown in Table 1, this requires 5 seconds, 1 second of processing 
time and 4 seconds of conunimication time. When the data control center forwards the return 
message to the point-of-sale terminal, the computer elapsed time for the data control center has 
increased by 5 seconds to 11 seconds. In the time stamp added to the message in line 4 of table 
2, the letter D indicates that the tune stamp was added by the data control center, the number 1 1 
indicates that the terminal elapsed time was 11 seconds, and the letters fd show that the data 
control center 11 forwarded a "authorization denied" code, which is different from the code issued 
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by the issuer. This indicates that an error has occurred at the data control center or in the data link 
between the issuer and the data control center. Also, when the data control center forwards the 
return message to the point-of-sale terminal, the terminal elapsed time has increased by 5 seconds 
to 13 seconds. 

DEPR: The point-of-sale terminal 1 receives the return message at substantially the same time as 
the message is forwarded by the data control center, so no communication time is required for this 
(line 8 of Table 1). The terminal adds a final time stamp that includes the terminal elapsed time 
to the message and logs the time stamps in the message. In the final time stamp shown added to 
the message m line 5 of table 2, the letter T shows that the tune stamp was added by the terminal, 
the number 13 indicates that the terminal elapsed time was 13 seconds, which is the total time 
required by the transaction authorization network to process the transaction. The letters rd in the 
final time stamp confirms that the return message received by the terminal 1 includes the 
erroneous "authorization denied" code introduced by the data control center or in the data link 
between the issuer and the data control center. 

DEPR: The point-of-sale terminal 1 receives a command fi-om a computer in the transaction 
authorizati on network from time-to-tune to upload the contents of its log for analysis. In the 
foUowmg example, the data fi-om the terminal has been uploaded to the computer of the issuer 21 
for analysis. The issuer's computer analyzes data from a plurality of point-of-sale terminals to 
identify those messages that are delayed, lost, or have errors to identify the parts of the network 
that cause the service provided by the network to fall below required performance standards. This 
information enables corrective action to be taken to remedy defects found. Such action can include 
shortening and/or hnproving communications paths, correcting software errors, adding 
communications and computer capacity, substituting dedicated conmiunications link for dial-up 
links. 

DEPR: In line 4, the issuer log shows that the transaction with serial number 1236 was approved 
by the issuer. However, the terminal log for the message 1236 includes only the final time stamp 
in which the number 45 indicates a terminal elapsed time of 45 seconds and the letter x indicates 
that the merchant cancelled the request for author iztion. The log entry for this message indicates 
that the return message authorizing the transaction was lost between the data control center 1 1 and 
the point-of-sale terminal 1. If the message had been lost between the computer of the issuer 21 
and the data control center, the data control center would have provided a response to the termmal 
(e.g., a "call me" code as in line 3) after failing to receive the message from the issuer within its 
time-out time. 

DEPR: The computer transit time is the time that elapses between the time at which the computer 
receives the message from the previous node in the network and the time at which the computer 
passes the message on to the next node in the network. For example, if the data control center 11 
receives a message from the point-of-sale terminal 1 at 10:00:00 hrs, but does not determine the 
issuer 21 of the payment card until 10:00:07, then immediately attempts to transmit the message 
to the issuer 21, but the issuer's computer is busy and does not give the go-ahead to transmit the 
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message until 10:00:10, the computer transit time is 10 seconds. 

DEPR: If even more data regarding the performance of the individual components of the 
transaction authorization network is desired, the computer time stamp can include additional time 
data, at the expense of even more time stamp overhead in the message. For instance, the computer 
transit time can be broken down into processing time, which is the time required by the computer 
to process the message, and communication time, which is the time required to transmit the 
processed message to the next node in the network, as shown in Table 1. 

DEPR: FIG. 4 shows how the third embodiment of the mvention is applied to the simple 
transaction approval network shown in FIG. 1. The pomt-of-sale terminal 1 adds a terminal time 
stamp to the message and transmits the message including the terminal time stamp to the data 
control center IL The data control center adds its "Computer D" time stamp to the message and 
forwards the message to the issuer 21. The message now includes two time stamps. The computer 
of the issuer processes the message, and transmits the processed message back to the data control 
center, adding its own "Computer I" tune stamp to the message. The message now includes three 
time stamps. The data control center adds a second "Computer D" time stamp to the message and 
forwards the message to the point-of-sale terminal. The message now includes four time stamps. 
When the point-of-sale terminal receives the return message, it adds a final time stamp to the 
message and logs the time stamps in the return message. 

DEPR: When the data control center 1 1 receives the message, it processes the message and 
forwards the message to the computer of the issuer 21. For the message shown in Table 1, this 
requires 3 seconds, 1 second of processing time and 2 seconds of conmiunication time. As the data 
control center forwards the message, it adds its computer time stamp to the message, as shown 
in line 2 of table 4. In this time stamp, the letter D shows that the time stamp was added by the 
data control center 11, the number 3 shows that the computer transit time was 3 seconds, and the 
letters fa show that the data control center forwarded an authorization request. 

DEPR: The data control center 11 receives the message from the computer of die issuer 21 and 
forwards the message to the point-of-sale terminal 1. For the message shown in Table 1, the 
computer transit time for die data control center is 5 seconds. 1 second to process the message and 
4 seconds of communication time. As it forwards the message, the data control center 1 1 adds a 
second time stamp to the message, as shown in line 4 of table 4. In this time stamp, the letter D 
shows that die time stamp was added by the data control center, the number 5 shows that the 
computer transit time was 5 seconds, and the letters fd indicate that an "authorization denied" code 
was forwarded. This code is different from the code issued by the computer of the issuer, which 
indicates that an error has occurred in the data control center 11 or in the communication link 
between the computer of the issuer and the data control center. 

CLPR: 1. In a transaction authorization network including a point-of-sale terminal and a central 
computer, wherein the point-of-sale terminal transmits a message regarding a transaction to the 
central computer, and the central computer processes the messa ge and transmits the message after 
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processing back to the point-of-sale terminal, a system for monitoring the quality of service 
provided by the transaction authorization network, comprising: 

CLPR: 27. In a transaction authorization network including a point-of-sale terminal and a central 
computer, wherein the point-of-sale terminal transmits a message regarding a transaction to the 
central computer^ and the central computer processes the message and transmits the message back 
after processing to the point-of-sale terminal, a system for monitoring the quality of service 
provided by the transaction authorization network, comprising: 

CLPR: 41. A point-of-sale terminal for use in a transaction authorization network including a 
central computer that receives and transmits messages, and adds message monitoring data to the 
messages that it transmits, the terminal comprising: 

CLPR: 54. A method of monitoring the quality of service provided by a transaction authorization 
network including a point-of-sale terminal and a central computer, wherein the point-of-sale 
terminal transmits a message regarding a transaction to the central computer, and the central 
computer processes the message and transmits the message after processing back to the point-of- 
sale terminal, the method comprising: 

CLPR: 67, A method of monitoring the quality of service provided by a transaction authorization 
network including a point-of-sale termmal and a central computer, wherein the point-of-sale 
terminal transmits a message regarding a transaction to the central computer, and the central 
computer processes the message and transmits the message after processing back to the point-of- 
sale terminal, the method comprising: 

CLPR: 68. The quality monitoring method of claim 67, wherem the step of adding, in the central 
computer, message monitormg data to the message includes adding the computer elapsed time to 
the message, the computer elapsed time being the tune that elapses between the time at which the 
central computer receives the message from the point-of-sale terminal and the time at which the 
central co mputer transmits the processed message back to the point-of-sale terminal. 
CLPV: the transaction authorization network further includes an additional computer disposed 
between the point-of-sale terminal and the central computer, the point-of-sale terminal transmits 
a message regarding a transaction to the additional computer, the additional computer transmits 
the message to the central computer, the central computer processes the message and transmits the 
processed message back to the additional computer, and the additional computer transmits the 
message back to the point-of-sale terminal, and 

CLPV: the transaction authorization network ftirther includes an additional computer disposed 
between the point-of-sale terminal and the central computer, the point-of-sale terminal transmits 
a message regarding a transaction to the additional computer, the additional computer transmits 
the message to the central computer , the central computer processes the message and transmits the 
processed message back to the additional computer, and the additional computer transmits the 
message back to the point-of-sale terminal, and 

CLPW: the computer elapsed time, the computer elapsed time being the time that elapses between 
the time at which the central computer receives the message from the point-of-sale terminal and 
the tune at which the central com puter transmits the processed message back to the point-of-sale 
terminal, 
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ABPL: A practical system and method for the remote distribution of financial services (e.g., home 
banking and bill-paying) involves distributing portable terminals to a user base. The terminals 
include a multi-line display, keys "pointing to" Imes on the display, and additional keys. Contact 
is established between the terminals and a central computer operated by a service provider, 
preferably over a dial-up telephone line and a packet data network. Information exchange between 
the central computer and the terminal solicits information from the terminal user related to 
requested financial services (e.g., for billpaying, the user provides payee selection and amount 
and his bank account PIN number). The central computer then transmits a message over a 
convention al ATM network debiting the user's bank account in real time, and may pay the 
specified payees the specified amount electronically or in other ways as appropriate. Payments and 
transfers may be scheduled in advance or on a periodic basis. Because the central computer 
interacts with the user's bank as a standard POS or ATM network node, no significant software 
changes are required at the banks' computers. The terminal interface is extremely user-friendly 
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and incorporates some features of standard ATM user interfaces so as to reduce new user anxiety. 

BSPR: The present invention relates to a method and system for distributing financial and other 
services to remote locations, and more specifically, provides banking type financial transaction 
handling via remote data terminals located in users* homes, offices or other locations (i.e., "home 
banking" or "remote banking"). Still more specifically, one aspect of the present invention 
involves using the ATM (automatic teller machine) network (interchange) as a data 
communications network for conducting banking financial transactions fi-om homes and offices. 

BSPR: While ATMs are very easy-to-use, they currently allow users to access only a limited 
number of bank teller services. A bank's own ATMs are typically connected by direct line to the 

bank's data processing system. The bank's data processing system^ in turn, communicates with 
a regional (or national) "ATM Network "-a specialized digital packet network which 
communicates ATM and PQS (point of sale) transactions among banks using standardized message 
protocols. These ATM networks and associated digital switches permit someone using the ATM 
of one bank to access an account in another bank, for example. 

BSPR: Some point-of-sale (POS) systems do exist which are capable of automatically generating 
debit requests and applying such debit requests to an ATM network (e.g., to result in immediately 
debiting a purchaser's account). Specifically, it appears that some such POS systems include a 
"concentrator" central computer connected to local modems. The local modems receive incoming 
calls over dialup telephone lines from remote POS stations located at retail sites. When a 
purchaser makes a purchase, he provides a magnetic stripe card which is encoded with identity 
and account information readable by the remote POS terminal. The purchaser also is required to 
input his PIN (personal identification number) for security reasons. The POS station automatically 
dials the central computer and transmits an identification of the retailer; purchaser bank and 
account information; and a dollar amount to be debited. The central computer reformats the POS 
request into a standardized POS debit request message which it transmits over the ATM network . 
The transmitted debit request causes the purchaser's bank account to be immediately debited, and 
may also provide a feedback message to the remote POS terminal indicating that the purchaser had 
an account balance exceeding the purchase amount and that the purchase amount has been 
successfully debited from the purchaser's bank account. Additional mechanisms cause the debited 
funds to eventually be paid to the retailer. 

BSPR: The two Hale patents relate to a specific dedicated home banking terminal and associated 
system. Grant et al broadly teaches a system which integrates banking and brokerage services via 
a data communications gateway between the two systems. The three Benton patents relate to 
details concerning personal banking/financial transaction terminals. Atalla et al teaches a portable 
banking terminal including data encryption capabilities and discusses conmiunicating over data 
communications lines with a data switch (see FIG. 1 and associated text). 

BSPR: Users preferably receive and view messages through a four line (e.g., by 24 or 30 
character) liquid crystal display (LCD). Instructions are communicated through a backlit display 
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adjacent to the LCD. Messages are communicated at high speed (e.g., 1200 baud) over dialup 
lines. The terminal takes advantage of significant human factors research and development 
performed by the U.S. Department of Defense and adopted by major ATM producers. By 
positioning selection ("soft") keys next to options displayed on the screen, users can more easily 
understand and quickly respond to instructions. Users thereby communicate by single-stroke 
responses to choices displayed, and the service provider has much greater system flexibility with 
which to format screens and expand services. 

BSPR; 6) Network Configuration: The ATM machine is usually connected to a bank's computer 
via telephone or hard line. Accounting information is provided by the bank's computer. 
Transactions that must b e passed to other banks are transmitted through the ATM network . Those 
ATMs that permit billpaying inventory the bills that are to be paid during the day at the ATM 
machine and are then posted after the close of the banking day by the bank. The ORL system 
passes bill payments directly through the ATM interchange (in the form of point-of-sale 
transactions) for debit and credit of accounts on a real-time basis. 

BSPR: Using an ATM network, the service provider pays customer bills by first debiting the 
user's account at his network bank-preferablv bv sending a POS debit message over the ATM 
network . Such standard POS messages not only permit the service provider to pass payee or other 
information over the network to the user's bank for use by the bank in generatmg a unified 
monthly statement, but also provide an automatic account inquiry /balance check fimction (so that 
the user does not overdraw his bank account inadvertently). Funds are transferred through the 
ATM network to the service provider's holding bank (or a clearing account maintained by the 
service provider in the user's bank). Payments are preferably processed inmiediately 
electronically, where feasible, either immediately or "warehoused" for a short time for transmittal 
with other user payments to a single payee. Otherwise bills are paid by paper check. 

BSPU: Anderson, "Electronic Funds Transfer is Reaching the Point-of-Sale; Banks. Retailers 
Look to EFT Transacti ons to Lessen Processing Costs, Increase Market Share", American Banker, 
p 32 (Jul. 28, 1982); and 

DEPR: FIG. 1 is a schematic block diagram of a presently preferred exemplary embodiment of 
a financial services distribution system 50 in accordance with the present invention. System 50 
includes a fault-tolerant central computer system 52 (hereafter referred to as "central computer"), 
a plurality of remote terminals 54, a digital packet network (e.g., "public data network"^ switch 

56 ("PDN switch"), packet assembler/disassembler 58 and associated asvnchronous 

conmiunic ations interface 60. and a dialup telephone network 62 selectively connecting remote 
terminal 54 to the communications interface. 

DEPR: Data is communicated between remote terminal 54 and central computer 52 through the 
PDN switch 56, the packet assembler/disassembler 58. the communications interface 60. and 
dialup telephone lines 62. 
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DEPR: In the preferred embodiment, PDN switch 56, packet assembler/disassembler 58 > 
asynchronous communications interface 60 and dialup telephone network 62 are entirely 
conventional and are preferably operated and maintained by a local or regional telephone 
company. Switch 56 may comprise, for example, a conventional public data network of the type 
which communicates packets in CCITT X.25 protocol between central computer 52 and packet 
assembler/disassembler 58. Similarly, packet assembler/disassembler 58 and asynchronous 
communications interface 60 may comprise conventional telephone company operated subsystems 
which convert the X.25 packet protocol existing on the PDN network into conventional 
asynchronous data format (e.g., with seven or eight data bits, a start bit, a stop bit and 
conventional error checking fields). 

DEPR: Asynchronous communications interface 60 initiates and answers dialup telephone 
communications with remote terminals 54. Thus, remote terminals 54 interface with the remainder 
of system 50 using standard asynchronous protocol, central computer 52 interfaces with the remote 
terminals using standard X.25 protocol, and conversions between the two protocols (as well as 
distribution of the signals generated by the central computer to specific remote terminals^ is 
handled b y the conventional PDN switch 56. packet assembler/disassembler 58 and 
communications interface 60 provided by the telephone company in the preferred embodiment. 

DEPR: Central computer 52 also interfaces with banking institutions and with other financial 
institutions 64 through the existing conventional automatic teller machine (ATM) interchange 
switch 66 (referred to herein as the "ATM network"). The ATM network is capable of 
communicating ATM transaction messages as well as point-of-sale (POS) messages in a 
conventional manner using standard message formats. As explained above, ATM switches 66 
communicate data in a specific, conventional interchange format between member banks or 
between automatic teller machines (ATMs) and member banks 64. In the preferred embodiment, 
central computer 52 is connected to ATM switch 66 (e.g., via one or more bisynchronous 9600 
baud communications lines) and communicates digital signals to the ATM switch using standard 
bisynchronous (e.g., point-to-pomt, SNA, etc.) conununications protocol. Thus, in the preferred 
embodiment, central computer 52 "looks like" an ATM or POS node connected to the ATM 
network and associated switch. Central computer 52 may generate account inquiry commands, 
commands to debit and credit accounts, and the like-just as would a bank's computer serving its 
ATMs or as would a stand-alone ATM or POS terminal. The ATM interchange switch 66 
processes such ATM conmiands generated by central computer 52 in the same way that they 
process commands generated by ATMs. Although the ATM interchange is ATM oriented, it is 
able to serve other terminal devices. For example, the ATM interchange communicates with retail 
POS terminals which can directly debit and credit a customer's bank account in payment for 
purchases. 

DEPR: It is also possible to provide direct dialup lines for communicating data between member 
banks 64 and central computer 52 (e.g., using standard communications protocols agreed upon 
by the bank's data processing svstem and bv central computer 52). Use of the ATM switch 66 and 
associated network to carry ATM/POS commands generated by central computer 52 avoids the 




need to provide any software modifications or other overheads within the member banks' data 
processing systems. Furthermore, use of the ATM switch 66 permits use of the network funds 
clearing process. 

DEPR: Central computer 52 also electronically communicates with additional remote data 
processing systems such as the Federal Reserve ACH 72 (e.g., via a Federal Reserve Bank data 
processing system 74), debit networks 76, wholesalers/remittance processors 78, direct payee 
computer systems 80, third party information providers 82 and advertisers 84. Such additional 
communications may be over dialup telephone lines if desired~or other special communications 
arrangements/protocols (e.g., magnetic tape transfer or the like) may be used depending upon 
particular applications. The link between central computer 52 and the Federal Reserve ACH 72 
permits payee commands to be electronically transferred to other banks using the existing Federal 
Reserve electronic funds transfer system. The link with wholesalers and remittance processors 78 
permits the payment of bills to a remittance center who in turn pays payees. The direct computer 
payee link 80 allows central computer 52 to contact individual desired payee computer systems 
and directly effect download of payment related data (e.g.. pursuant to a daily "clearing" process 
). The link to advertisers 84 may be used to transfer advertiser copy between the advertiser and 
the central computer system and to pass back to the advertiser the names of those customers who 
request information in response to advertisements. 

DEPR: As mentioned above, many or most of the software-controlled operations performed by 
CPU 80 in the preferred embodiment are conventional and well-known in the banking industry. 
For example, it is conventional and well known to communicate standard ATM and POS messages 
between a central comp uter and an ATM network using conventional off-the shelf ATM and POS 
software, and central computer 52 in the preferred embodhnent utilizes such conventional software 
to generate and communicate appropriate messages over the ATM network 66. Conventional 
banking software packages exist which perform a variety of exceedingly complex but entirely 
conventional fiinctions (e.g., maintaining audit trails to ensure transaction reliability, maintaining 
user account and vender files, providing clearing information at night, etc.) and the preferred 
embodiment central computer 52 executes such conventional banking software modules to perform 
such standard functions. Conventional database handling ftinctions are also typically integrated 
into banking and POS software modules to maintain customer information. 

DEPR: The interchange interface module 801 in the preferred embodiment enables the fault- 
tolerant computer system 52 to interface with the interchange network in a conventional manner. 
This module 801 converts internal system transaction information to a format that is compatible 
with that of the network. In addition, a log is conventionally maintained of all transaction 
communicated between the system and the network . 

DEPR: For example, a user having a bank account in bank A (the "on us" bank) connected to the 
Internet ATM network may use the ATM machine of bank B (a "foreign" bank) to withdraw from 
his bank A account. The mainframe computer of bank B generates, in response to the user's 
request via the ATM message specifying the user's PIN (personal identification number), the 
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user's account number, the user's bank and the amount to be withdrawn. This ATM withdrawal 
message is then sent over the ATM network and is received by the computer of bank A. Bank A 
checks the message for validity (i.e., to make sure the PIN is correct), determines whether the 
user has a sufficient account balance to honor the withdrawal request (the message processing thus 
provide an automatic account balance check), and then processes the request by posting a debit 
memo against the user's bank account (the bank A computer does not actually withdraw fiinds 
from the user's account at this time, but will process the memo during the posting and settlement 
process later that day). The bank A computer then Bends a confirmation message back over the 
ATM network to the bank B computer confmning that the user's account has been debited and that 
at clearing time bank A will pay the funds to bank B. Based on receipt of the confirmation 
message over the ATM network, the bank B computer controls the bank B ATM machine to 
dispense the requested funds to the ATM user. 

DEPR: Similarly, a chain of retail stores may permit processing of so-called "debit cards" (like 
credit cards, but rather than credit being extended by a lending institution to cover purchases, a 
debit card results in an immediate electronic debit of the user's bank account). A customer 
provides the retailer with his debit card which the retailer magnetically reads (e.g., using a 
"swipe" type magnetic card reader). The customer is then asked by the retailer to secretly key in 
his PIN into a keyboard, and the retailer keys m the amount of the purchase. A POS debit request 
digital message is then transmitted either directly over an ATM network (or indirectly via a dialup 
or dedicated telephone line and a central concentrator computer) for receipt by the user's bank. 
The POS debit request digital message typically contains the user's bank designation and bank 
account designation; the user's PIN (which is typically encrypted); the name or other designation 
of the retailer; and the amount of the purchase. The user's bank computer receives the POS debit 
request mes sage from the ATM network, processes it for validity (i.e., valid PIN, valid account), 
ensures the user's account balance is in excess of the debit request, and then debits the user's 
account (i.e., by posting a debit memo) and credits the retailer's account electronically (this 
typically requires the retailer to have worked out an arrangement with the particular user's bank 
beforehand). The bank transmits a confirmation message to the POS terminal over the ATM 
network which, when received, assures the retailer that the funds are available and have been 
transferred to his account. 

DEPR: If during a terminal session a period passes when there is no key activity for a certain time 
delay, terminal 54 tunes out and disconnects the telephone link with the PDN switch 56. In the 
preferred embodiment, transactions requested prior to such c ommunications failure are not 
processed by central computer 52 unless the user has received a confumation over terminal 54 that 
the requested transaction has been processed. 

DEPR: If the payment is to be paid other than today (a "future payment"), a similar logging 
procedure is followed, except that the payment (along with certain secured PIN information) is 
routed to a payment transaction pending file instead of being processed for immediate payment. 
On the appropriate day of payment, the transaction pending file is accessed and the information 
necessary to affect an account debit of a user's bank account is retrieved and a corresponding POS 
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debit message is generated and sent over the ATM network at that time. 

DEPR: The final selection permits the user to SIGNOFF the terminal, or move to another account 
at the same bank or a different bank. If the terminal session is ended, a session number and 
message is transmitted to the terminal (die session number is stored by the central processor and 
is used for customer servicing and reference). Actual bank debit and credit processing that was 
not initiated during the session is completed after the terminal session ends. The terminal detects 
an end of session code and the modem is commanded to break the communications. If the terminal 
session ends abnormally due to a failure in the communications link, those transactions that were 
not entered up to the point of confirmation are not executed by the central processor. The terminal 
user, once receiving indications that the communications link is down, must push the ON key to 
reestablish a communications link and continue with his remaining transactions . He can review 
his online statement of transactions to conform what transactions have been accepted by the central 
processor. 

DEPR: Central computer 52 then preferably sends an additional display screen to remote terminal 
54 asking the user whether he wants additional information (block 382) via an additional call to 
the TIOT routme. Preferably a 3-second time response is initiated at this point so that if the user 
does not respond within three seconds the central computer goes on and executes return 386 to the 
FIG. 9 main routine If the user responds with a "yes" response (i.e., by depressing the appropriate 
one of select keys 108 "pointing to" a line of information displayed on display 102 indicating 
"yes" response), central computer 52 stores the user address and other appropriate information 
into a file which is sent (e.g.. elec tronically via a dialup line ) to the user's bank (or other 
advertiser) so that the advertiser can directly contact the user by mail, telephone (perhaps using 
autodial to get immediate access to the user after he terminates his termmal session) or otherwise 
to provide additional information about the advertised service or merchandise (block 384). On 
executing return block 386, the main menu routine is called to permit the user to select financial 
transactions to be performed (see FIG. 9, block 388). A flow chart of exemplary program control 
steps included in this main menu routine is shown in FIG. 12. 

DEPR: Referring now to FIG. 13, the "bill process" routine 392 performs the ftinction of 
processing, reviewing and correcting billing information-and also permitting the user to 
electronically request fimds to be debited from his bank account and used to pay bills to particular 
desired creditors on specified dates. Upon selecting the "pay bill" main menu option, bill process 
routine 392 may provide account balance information to the user by forming a standard account 
balance ATM or POS type message (or possibly using a "null" POS debit message) containing the 
user's account number and PIN and transmitting this request over the ATM network to the user's 
bank; receiving the user's account balance from the user's bank over the ATM network in the 
form of a return ATM message; reformatting this received account balance information; and 
transmitting the account balance to the remote terminal 54 using the TIOT routine discussed earlier 
(block 502). Central computer 52 may also temporarily store this account balance in the preferred 
embodiment for purposes of keeping a running total, as will be explained. 
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DEPR: In the preferred embodiment, central computer 52 appears on the ATM network as simply 
another ATM machine or POS node-and uses the same standard messaging formats used by ATM 
machines and POS terminals to obtain and receive information from the user's bank. Included in 
the ATM/POS communications format/protocol standard used by the ATM interchange network 
described previously is a command format to request account balance information. Central 
computer 52 generates such an account balance request using the account number (and preferably 
also the user PIN number) provided by the user earlier, then receives from the ATM network a 
response containing the account balance pertaining to the user*s bank account. Since this account 
inquiry request generated by central computer 52 "looks like" a request generated by any ordinary 
ATM or POS device, the user's bank's data processing system and the ATM network are capable 
of handling this request in a routme, ordinary way (and no software changes at the bank's end are 
required to respond to such messages). 

DEPR: Referring to FIG. 18, a flow chart of exemplary program control steps performed as part 
of the BALCHECK routine 698, central computer 52 compares the requested payment amount 
with the balance remaining in the user's bank account assuming all immediately scheduled 
payments are processed (decision block 700). As described previously, in the preferred 
embodiment central computer 52 obtains the user's current bank account balance via a "account 
inquiry" request transmitted over the ATM network 66. Central computer 52 progressively debits 
the amount of this balance as the user schedules payments to be processed immediately~so that 
the central computer maintains a running balance of the user's account without yet actually 
debiting the user's account electronically. If the desired payment exceeds the user's remaining 
balance, an error flag is set (block 702). Otherwise, an error message will be sent (block 704) and 
the error flag is set (block 706) before a return to FIG. 17 block 708 is performed. 

DEPR: Referring now to FIG. 20C, if the user confirms the account transfer request ("yes" exit 
of decision block 826 of FIG. 20B), central computer 52 prompts the user whether transfer is to 
be performed immediately and receives the user's response. If the user requests an immediate 
transfer (the "yes" exit of decision block 824), the confirmation message is transmitted to remote 
terminal 54 (block 826). The user may be asked to input the PIN of the account to transfer money 
into at this time. Central computer 52 then generates a pair of messages to be applied to the ATM 
network 66: a POS debit to the account to transfer money from and POS credit to the account to 
transfer money into. These two accounts need not be in the same bank, since central computer 52 
may reach any bank on the ATM network with the messages. In effect, the real-tune transaction 
is to: (a) debit the user's first bank account and credit the services provider's account; and (b) 
credit the user's second bank account and debit the service provider's account (the net result bemg 
a funds transfer). In the case where this methodology is not appropriate or feasible, debits are 
processed as normal A TM/POS transactions and credits are made bv ACH. magnetic tape or other 
electronic means to the user's bank. 

DEPR: Referring now more particularly to FIGS. 21 A-21C, central computer 52 sends to terminal 
54 a display format announcing that "account information service" is being provided and then 
present the user with various options to select (e.g., "account balance", "statement of activity". 
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and "other bank information"). If the user selects the account balance option (as tested for by 
decision block 950), the preferred embodiment central computer 52 transmits the balance of the 
"primary" account (block 952). This "primary" account designated by the user in advance (i.e., 
when he first subscribes to the remote financial distribution service or when he logs onto his 
remote terminal at the beginning of the current session) and is probably the account the balance 
of which the user is interested in. Following this account balance display, central computer 52 
transmits an additional display screen to terminal 54 presenting the user with the following 
additional options: "balance for other account", "access other services" and "end this online 
banking session". If the user then selects the "other account balance" option (tested for by decision 
block 954), central computer 52 controls terminal display 102 to display a listing of the user's 
other accounts (block 956) and permits the user to scroll through the list to select another account 
(blocks 958-962). If the end of the list is reached (tested for by decision block 962), control is 
returned to the "account balance" prompt (block 950). If the user selects another account, on the 
other hand, central computer 52 transmits a designation of this account along with its balance 
(and, if necessary, generates a request on ATM's network 66 obtaining this account balance) 
(block 964). A request for "other services" in the preferred embodiment is handled by returning 
the user to the main menu routme 368 (blocks 966-968), while an "end session" request is handled 
by calling the SESSEXIT routine to be discussed shortly (blocks 970, 972). 

CLPR: 2. A method as in claim 1 wherein said step (c) comprises the step of settling funds by 
electronically communicating payment data across a network of electronic lockboxes. 

CLPV: (c) applying the generated ATM network compatible request message to said interbank 
financial services network so as to route the ATM network compatible request message to a 
selected one of said multiple financial institutions and effect a real time debit or credit financial 
transaction at said selected financial institution so as to shift liability to said selected financial 
institution in real time; 

ORPL: International Banker, Jul. 28, 1982, p. 32, Anderson, "Electronic funds transfer is 
reachmg the point-of-sale; banks, retailers look to EFT transactions to lessen processing costs". 
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BSPR: The foregoing objects are accomplished in an embodiment of the present invention by a 
financial transaction processing system in which transaction messages are routed to and from card 
activated terminal devices. The card activated devices are commonly point of sale terminals and 
automated teller machines. Transaction messages are transmitted from the terminal devices to an 
authorization subsyste m or network . The authorization subsystem may be integral with the 
financial transaction processing system of the present invention or may be a separate and distinct 
external system or network of systems. Transaction messages from the authorization subsystem 
are routed through the system of the present invention and back to the proper terminal device. 

DEPR: Of course, in most financial transaction systems it is necessary to accept cards other than 
those which may have been issued by a particular retailer. Such cards commonly include 
MasterCard.RTM. , VISA.RTM. , American Express. RTM. , Diner's Clubs.RTM. , 
Discover. RTM. and other credit or debit cards. As a result, it is often necessary to have software 
applications which will route these transactions from the system to the proper external 
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authorization network and back again. Such programs are schematically represented by the switch 
support application 48. 

DEPR: Using the GUI creation tools, high level graphic representations of system components 
including hardware and software are provided which may be manipulated by a systems operator. 
Such manipulation may include the ability to add or delete terminal and network connections to 
the system, to reconfigure the system to communicate with different terminals and networks, and 
to add, delete and modify the information to be used by the various application programs. The 
graphical user interface software component may also be used to select various types of terminal 
o n-line connections which will then change message routing . The user is enabled to input the 
desired changes using input devices such as a keyboard or mouse and to observe the results of the 
changes on the display. The GUI enables the user to configure the system at a high level. The 
user's configuration changes the underlying database relationships so the system changes its 
operation to conform to the changes input through the graphical user interface. 

DEPR: As shown in FIG. 11, the ARP 76 operates to access data which is stored in the database, 
but which is preferably available in block memory in RAM when the system is running because 
of the shared memory feature of the system. The database includes data representative of system 
"nodes", each node corresponding to a component of the system. One data block includes node 
table records associated with the particular line and/or terminals attached to the line which is 
sending the message to the system. This data is laid out in a node table record 78 which is partially 
shown schematically in FIG. 11. The node table record 78 contains considerable information 
associated with the line and/or terminal from which the message is coming. By matching the node 
table record containing the physical address data which has been delivered to ARP 76, with the 
node table records in memory, the system can find a node ID which is called a NODE_SID in 
table record 78. The NODE^SID is determined by matching the node table record which has the 
corresponding physical address data therein. The ARP 76 then operates to obtain the NODE SID 
value fi-om the node table record 78. The ARP 76 then places the NODE_SID value in field 2 of 
the header. The NODE_SID is the system identifier used in the system to identify the particular 
component in the system which sends or receives a message. 

DEPR: The message is now ready to be sent to the message gateway router 24. In this example 
only fields 1, 2, 3, 7, 8, 10 and 12 in the SME are filled in with data by the line driver. In other 
examples where the terminal which originated the message is part of a line group the ARP 76 also 
inserts the NODE SID of the node type line table record associated with the line driver which 
receives th e message, in field 1 1 of the SME. This is necessary to make sure that a message that 
is responsive to the original message can find its way back to the line that the original message 
came in on. This is important for handling dial up devices which may have messages come in on 
any of several phone lines. The data in field 11 enables a responsive message to be routed back 
to the device on the line which remains open during processing of the transaction. If the 
component sending the message alwavs uses a designated line for c ommunication with the system, 
field 11 of the SME is not used. 



DEPR: The sender uses the SERVER SID value to determine the IP address and IP port ID of 
the required MP? so that the message may be sent to that MPP through the TCP/IP network . The 
sender goes to the database information in the memory and finds a server table which includes that 
SERVER SID value from the node table record. The server table is partially graphically 
represented 106 in FIG. 15. From the server table the sender retrieves the IP address designated 
IP ADDR in the table. The IP_PORTJD is known from the node type process table record. 
Using the application programming interface ("API") associated with Unix, or other operating 
system bemg used, the message is sent through the TCP/IP network to the designated IP address 
and specific IP port ID. 

DEPR: The MPP functions to process an incoming message and to generate a new message. This 
processing of a message by an MPP may involve, for example, a request to authorize a financial 
transaction and generating a message in response. This response message would typically allow 
the transaction to go forward, or to deny the transaction. In this example the MPP would be 
generating a return message which is routed back to the originating terminal device. Alternatively, 
the MPP may perform processing on the message and then send the resulting message through the 
svstem for eventual transmission to an external network or other external authorizing system. 

DEPR: The MPP 108 must also derive information concerning where to send the message next. 
For purposes of this example, we consider a situation where a transaction message is eventually 
going to be transmitted to an external network for authorization. The identity of the network can 
be derived by MPP 108 through association with data in the primary account number ("PAN") 
within the ISO 8583 message. The process of deriving the address of the ultimate system node 
where the message can be processed is done by the MPP 108 and is demonstrated schematically 
with reference to FIG. 30. 

DEPR: The MPP 108 also derives the SERVICE SID of an MPP that can next process the new 
message . The MPP 108 also has available the TARGET_NODE_SID value of the external 
network wh ich will receive the new message . This data can be used to complete the data that is 
needed for fields 5 and 6 of the SME header. 

DEPR: The MPP 108 then takes the message type for the new ISO message it has generated. The 
MPP goes through the message map tables in shared memory which have the 
OUT_MSG_FMT_SID of the external network (ultimate target node). The MPP finds a message 
map table record which has the MSG_TYPE of its new message. This then provides the 
INT MSG SID value which corresponds to the message type being sent and the format used by 
the externa l network . (See message map table layout in FIG. 22.) 

DEPR: The MPP 108 then derives the SERVICE SID for an MPP that can process the messag e 
that is going to the external network. This is done by the MPP 108 finding a message router table 
record which includes the NODE SID for the external network and the INT MSG SID for the 
message the external network is going to receive . As shown by the layout of message router 
tables in FIG. 29, the table record with both of these values includes the SERVICE SID of the 



MPP that can process the message . The SERVICE SID value for this next MPP can be inserted 
in field 5 of the reader, or if the message is not going directly to an MPP, may be stored in a 
private field of the message in field 12 for later use. Storage for later use may be done where the 
message is first going to a timer component before the next MPP, as later discussed. 

DEPR: As shown in FIG. 5 MPP 108 has a sender 122 associated therewith. Sender 122 operates 
to derive the address of the component in the system which will receive the message from MPP 
108. The sender does this by deriving the IP address and IP port ID for the component in the 
TCP/IP network which will receive the message . All senders of components in the system have 
the same capabilities. 

DEPR: Alternatively, in response to the message direction being set to "MPP to MPP", the sender 
uses the SERVICE_SID value in field 5 to determine the next system address. As shown in FIG. 
29 the service provider table record with the SERVICE SID value from field 5 provides the 
sender 122 with the NODE SID of the MPP which can next process the message. Having found 
the NODE SID value for the next MPP 138, the sender 122 executes the steps described above 
to find the IP ADDR and IP PORT ID values for MPP 138. The sender then sends the message 
through the TCP/IP network to MPP 138. 

DEPR: As shown in FIG. 6 MPP 138 has an associated listener 136. Listener 136 receives the 
message sent bv sender 122 through the TCP/IP network of the system. The listener reconstitutes 
the message and puts it in a queue for the MPP. 

DEPR: MPP 138 is configured to look for the target node sid of the external network in the 
messages it receives . This is accomplished responsive to the "data source" indicator in field 7 of 
the incoming message. If the message indicates that its source is an "internal source" (either as 
set by MPP 108 or by an intermediate timer) MPP 138 obtains the node value from the private 
field. If the message source was set to "external source" the MPP 138 will either use the target 
node in field 6 of the incoming message, or will derive the target node value in accordance with 
its configuration. 

DEPR: Field 5 is the SERVICE_SID of the MPP that will next process the message . Because in 
this example the message is heading out of the system to a network and not to an MPP, this value 
is null. 

DEPR: The sender 140 sends the message through the internal TCP/IP network to the address of 
MGR 164. MGR has a listener 142 that receives the message and reconstitutes it. The listener then 
places the message m a queue of the MGR. It should be understood that MGR 164 may reside on 
the same or a different computer from MPP 138. 

DEPR: After the new message is built the MGR 164 delivers the message with the header fields 
it received, to the driver 144 through the IPC. The appropriate driver is derived by the MGR as 
the parent node of the external network. The driver strips the internal header and then puts the 



needed protocol portions on the new raw message in accordance with the API of the particular 
external authorization system. The driver sends the message to the ex ternal authorizing network 
146. 

DEPR: In the transaction example described so far the system of the invention has received a 
message from POS terminal 68. The system has transformed the message from the external 
terminal format to the internal format of the system in MGR 81. The system processed the 
incoming message in MPP 108 to generate a new message. The new message was processed in 
MPP 138 to generate a further new message to the external network. The message from MPP 138 
was transformed by MGR 164 into an external format for the external network 146 and the 
message has been sent . 

DEPR: The ARP portion of the driver 144 resolves the NODE SID record value for the external 
network 146 based on the physical address. The driver inputs the NODE SID value for the 
external network in the header as the originating node and sends the message through the IPC to 
MGR 164. 

DEPR: A sender 152 of the MGR responds to the "in" message direction in field 8 of the header 
to find the system address of the MPP that can process the message. This is done using values in 
node table record for the MPP and the server table records in the manner previously discussed. 
Sender 152 sends the message to that MPP through the TCP/IP network . 

DEPR: The MPP to which messages from the external network 146 are routed by the MGR 164 
will preferably be MPP 138. This is because MPP 138 is the MPP that deals with messages in the 
format of that external network. As shown by the state flow table record layouts in FIG. 25, the 
MPPs of the preferred embodiment of the invention include table records which correspond to a 
plurality of message types. Of course for each message type there are generally a plurality state 
numbers which direct state flow processes for generating the field values of a new message. 

DEPR: MPP 138 is configured to carry out state flow processes in response to receiving a return 
type message. Part of this configuration is to use the values in the "echo back" fields of the ISO 
message to route its new message back to the MPP 108 that is to receive the response. MPP 138 
receives the data from the TCP/IP network through its listener 136 which places it in a queue to 
the MPP. The MPP then places the message data in its first cell array. The MPP then operates to 
take the "echo back" data to its transaction record file in database 32. Upon finding a match of 
the echo back data in a message stored as a transaction record, it retrieves the message from the 
transaction record file. This record preferably includes NODE^SID and/or SERVICE^SID values 
for MPP 108. The MPPs in the system which receive response messages have the capability of 
recovering the data from the data store that can be used to direct the message to the appropriate 
system component. 

DEPR: Continuing with the example in which a response message is going back to terminal 68, 
the MPP 138 has built the fields of a new message in its final cell array. The MPP generates the 



new message in the SME format. MPP 138 delivers the new message to its sender 140. Sender 
140 derives the system address based on the message direction and corresponding SERVICE SID 
or TARGET NODE value in the header. The sender sends the messa ge to MPP 108 through the 
TCP/IP network . 

DEPR: The MPP 108 sends its resulting message to its sender 122. Sender 122 derives the system 
address of MGR 81 based on the "out" message direction and the "parent-child" relationships 
between the terminal, its driver and the MGR. The first "parent-child" relationship is found in the 
node table record for the terminal 68 which is the TARGET NODE SID, and its line driver 70. 
The "parent-child" relationship in the node table record for line driver 70 indicates that MGR 81 
is the parent node of the line driver. This enables the sender 122 to derive the NODE_SID for the 
MGR. The sender derives the IP PORT ID and IP ADDR values for MGR 81 and sends the 
message to the MGR throu gh the TCP/TP network . 

DEPR: The outgoing message is sent from MGR 81 to line driver 70. The line driver strips die 
SME header and adds the protocol information for the termmal. The driver 70 delivers the 
outgoing message to the terminal 68. The system is now ready to receive another message from 
terminal 68. 

DEPR: In the transaction example, the message going fi-om MPP 108 to MPP 138 would be 
passed through the tuner 150. This is accomplished by MPP 108, after deriving the system address 
for MPP 138, executing father state flows in accordance with its configuration. This processing 
places the NODE_SID for MPP 138 (or the SERVICE SID value for MPP 138 if that approach 
is used) and the INT_MSG_SID value, in a selected ISO private field in field 12 of the message. 
The MPP 108 also resolves and puts a time for response to the message in a private field in the 
ISO message. MPP 108 also puts its own NODE_SID value in a private field. The MPP 108 then 
puts the NODE SID for the timer 150 in field 6 of the header and sets the message direction to 
"out". MPP 108 then sends the message through the TCP/IP network to the timer. 

DEPR: The sender 122 of the MPP 108 responds to the message direction set to "out" to derive 
the system address of MGR 124 based on the "parent-child" relationships of the line driver 172 
to the timer 150, and the MGR 124 to the line driver 172, respectively. This is done by sender 
122 in the manner previously discussed using the node table records. The sender 122 then 
determines IP_PORT_ID and IP_ADDRESS value for the MGR 124 and sends the message 
through the TCP/IP network . 

DEPR: The MGR 124 passes the message to the line driver which strips the header and sends the 
ISO message to the tuner 150. The tuner processes and stores a modified version of the original 
ISO message in its queue in designated RAM 148. The stored message includes the "echo back" 
data as well as the NODE_SID value of MPP 108 which originated the message. The timer is 
configured to take the time out of the private field and uses it as a trigger to produce a message 
back to MPP 108 if the message is not deleted from the timer queue prior to that time. The timer 
also modifies the message so that it includes an mdicator in a selected private field that it is a 




"time out" message. The timer also places the NODE^SID value for MPP 108 in the header 
before storing the message in its queue. 

DEPR: After the timer 150 stores the time out message, the timer preferably takes the original 
message it received and moves the NODE_SID for MPP 138 (or SERVICE_SID if that approach 
is used) and the INT_MSG_SID out of the private field. The timer places these values in the 
appropriate fields in the header to send the message to MPP 138. The timer also changes the 
message direction in the header to the value appropriate to route to MPP 138. The timer then 
sends the message to the line driver. The line driver derives a NODE_SID value of the timer 
which shows that the incoming message is in the internal ISO SME format. The line driver 
responds to the fact that the incoming message is already in the internal format to pass it to the 
MGR 124. 

DEPR: MGR 124 operates responsive to the IN_MSG_FMT_SID presence of the message which 
indicates that it is already in the SME format of the system. As no reformatting of the message 
is required, the MGR 124 copies the message it received from the timer and delivers it to its 
sender 170. Sender 170 transmits the message through the internal TCP/IP network to MPP 138 
in accordance with the header data on the message. 

DEPR: The responsive message from network 146 is routed back to MPP 138 in the manner 
previously described. MPP 138 uses the "echo back" data to route the message back to MPP 108 
and to terminal 68. MPP 108 executes state flow processes which update its transaction records 
in the database 32. The MPP 108 also includes a state flow process that is performed responsive 
to finding the corresponding outgoing message to a new incoming message. This state flow 
process in MPP 108 generates a message to the tuner 150 to delete the transaction in its queue 
having corresponding data in the selected private field. If this message is received by the timer 
150 before the time set in the timer expires, the original message data is deleted fi-om its queue. 
The message sent by MPP 108 to the timer 150 includes an indicator in a private field in the ISO 
message that it is a "delete" message. 

DEPR: If however, the time set in conjunction with a message in the queue of timer 150 expires 
before a delete message is received, the timer operates to send a "time out" message back to MPP 
108. The tuner delivers the message to the line driver 172. The line driver responds to the 
INT_MSG_SID corresponding to the SME ISO format to pass the message without reformatting 
to MGR 124. The MGR likewise responds to the message already being in the internal system 
format to copy and pass the message to its sender without reformatting the message. Sender 170 
sends the message through the internal TCP/IP network to MPP 108. 

DEPR: New types of external devices (including external networks) which send and receive 
messages can be connected to the system of the present invention. This is done by configuring 
node table records with the characteristics of the device. Accommodating such a new device 
requires configuring one (or more) MPPs to handle messages to and from the new device. This 
process is generally much simpler than what is required to accommodate connection of new 
devices or systems to conventional financial transaction processing systems. 
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US-PAT-NO: 6336590 
DOCUMENT-IDENTIFIER: US 6336590 Bl 
TITLE: Electronic funds transfer network test system 
DATE-ISSUED: January 8, 2002 
INVENTOR-INFORMATION: 

NAME CITY STATE ZIP CODE COUNTRY 

Kubitz; Carl Scottsdale AZ N/A N/A 

US-CL-CURRENT: 235/479,235/375 

ABSTRACT: A system is described which permits a financial institution to provide for testing 
of software and equipment which is intended for use in an electronic funds transfer network. The 
system permits the validation of the software and equipment without requiring utilizing the 
electronic funds transfer central switch which would otherwise process electronic fimds transfers. 
24 Claims, 5 Drawing figures 
Exemplary Claim Number: 1 
Number of Drawing Sheets: 3 

KWIC 

BSPR: The banks do not communicate directly with each other. Instead, they both communicate 
with a central org anization that acts as a clearing house providing an electronic data interchange. 
Examples of such central clearmg houses are Star, Mac, Plus, and Explore. These organizations 
provide services to their member institutions. Their main technical role is to operate a computer, 
called a "switch", that manages the exchange of these transactions. The first six digits of an ATM 
card are the bank identification number. The ATM card number is provided to a switch which in 
turn identifies the destination bank and routes the accompanying transaction . ATMs display the 
logos of the central clearing house systems which they recognize. Credit and debit cards in 
people's wallets display these same names. 

DEPR: The process of testing and validating data exchanges between switch 100 and bank 101 
is an iterative process. A system 1000 in accordance with the invention as shown in FIG. 2 
receives data. The data is then compared to data standards. Differences between the data and the 
standards is logged and the data are transmitted. 

CLPR: 12. A system for use in pre-certification testing of financial institution apparatus intended 
for electronic interchange of data with an electronic ftinds transaction switch, said apparatus 
comprising an interfa ce to a communications link with said switch, said system comprising: 

CLPV: validating messages received from said apparatus via said second communications link ; 
and 
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4 ^COPYRIGHT 1999 DERWENT INFORMATION LTD 14^ 

TITLE: System for providing a customer of a bank with a home bank terminal interface at a 

remote terminal, uses a private data field in a financial transaction message to pass appropriate 

data through the routing system of a financial institution 

INVENTOR-NAME: DOWNING, J; ZAHORIK, G W 

PRIORITY-DATA: 1999US-131066P (April 26, 1999) 

PATENT-FAMILY: 

PUB-NO PUB-DATE LANGUAGE PAGES MAIN-IPC 

EP 1049057 A2 November 2, 2000 E 016 G07F 019/00 

JP 2000348106 A December 15, 2000 N/A 051 G06F 017/60 

INT-CL (IPC): G06F017/60; G07F019/00 
ABSTRACTED-PUB-NO: EP 1049057A 

BASIC-ABSTRACT: NOVELTY - Customer (2) of a bank with home bank terminal (10) may 
contact the home bank via remote transaction terminal (4) through routing and settlement system 
(6). Remote terminal sends a request, along with customer identification, to home bank server (8) 
which then includes private data (44) in its response financial transaction message (40) to enable 
the remote transaction terminal to provide an interface to customer similar to the home bank 
terminal interface. 

DETAILED DESCRIPTION - INDEPENDENT CLAIMS are also included for the following: 

(a) a method of communicating messages for a customer between a remote transaction terminal 
and a home data center of a financial institution; 

(b) a method of providing a customer with a home bank terminal interface experience; 

(c) an system for providing a customer of a home bank with a home bank terminal interface 
experience at a remote transaction terminal 

(d) a system for communicating messages for a customer between a remote transaction terminal 
and a home data center of a financial institution 

(e) a method of communicating in a financial network 

(f) a financial transaction message 

(g) a method of communicating in an int ernet based transaction . 

USE - For tunneling messages related to financial transactions through Electronic Fund Transfer 
routing and settlement systems such that a remote terminal interface may operate according to the 
home bank terminal interface of a customer or such that private data may be passed between a 
financial institution and a customer during an internet transaction with a web merchant. 

ADVANTAGE - The system provides a customer at a remote terminal with a familiar interface, 
thus transactions are easier for the customer to execute with reduced chance of error and probably 
more quickly. The familiar interface at remote terminals helps to build customer loyalty. New 
products can be quickly introduced, secure payments and communication are possible with the 
ability to authenticate customers, merchants to avoid fraud. 
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DESCRIPTION OF DRAWING(S) - Two figures are used, fig. 1 shows a schematic overview 
of the communication system and fig. 4 shows a graphical representation of a data structure. 
Customer 2 

Remote transaction terminal 4 

Routing and settlement system 6 

Home bank server 8 

Home bank terminal 10 

Response financial transaction message 40 

Private data 44 
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